@ashishSoni1234 is attempting to deploy a commit to the Different AI Team on Vercel.

A member of the Team first needs to authorize it.

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openwork-landing	Ready	Preview, Comment, Open in v0	Jun 18, 2026 4:20am

Verified this on Windows. The change is safe and fixes a real Windows correctness issue — but a few things worth nailing down before it lands, since it's a security fix.

What I checked

• Ran a battery of traversal payloads through normalizeWorkspaceRelativePath (../etc, .., a/../../etc, the Windows form ..\..\etc, workspace/../../secret) — all blocked. Notably they're blocked on the pre-PR code too: the existing per-part .. check already rejects them. The new posix.normalize block's main observable effect is that an in-bounds path like a/b/../c.txt is now accepted (-> a/c.txt) instead of rejected.
• resolveSafeChildPath: the new case-insensitive Windows comparison fixes a genuine false-rejection — a path differing only in case (c:\users\me\ws vs C:\Users\Me\WS) was rejected before, accepted now. Confirmed it doesn't open an escape: an outside path (C:\Windows\System32) is still rejected regardless of case, and the + sep boundary correctly rejects the WS vs WS-evil sibling-prefix case.
• pnpm --filter ./apps/server typecheck -> clean.

Questions / suggestions:

1. Does this actually close [Bug]: The agent's access path escaped from workspace. #2285, and could we get a regression test? Relative .. traversal was already blocked before this PR, and the case-insensitive change relaxes resolveSafeChildPath (fixes a false-rejection) rather than tightening it — so I can't tell which line addresses "the agent reached the parent directory." Since the issue has no repro steps, a test that reproduces the escape and asserts the 400 would confirm the real vector is fixed and lock it in. Related: does the agent's file access in [Bug]: The agent's access path escaped from workspace. #2285 go through routes/files.ts, or through the opencode engine's own file tools? If the latter, this may be defense-in-depth rather than the fix site.

2. Duplicate guard: there's a second resolveSafeChildPath in apps/server/src/extensions/openai-image-generation.ts (~line 101) still using the old case-sensitive check. Lower risk there (its input is an internally-generated artifacts/<name>.png), but the boundary logic now differs between two copies of a security primitive — maybe worth a shared helper so they don't drift.

3. (minor) Containment is textual (resolve, not realpath), so a symlink inside the workspace pointing outside wouldn't be caught. Probably out of scope, just noting it since this is the sandbox boundary.

The Windows case-insensitivity fix is a real improvement regardless. Mainly want to make sure the #2285 escape itself is covered (and tested).

Nice layered approach. Walking through it: raw.replace(/\\/g, "/") up front means Windows backslash traversal (..\..\) folds into the posix check, and the trailing sep in rootResolved + sep blocks the sibling-prefix case (/ws1 vs /ws1-secret), so the boundary check holds up.

One thing worth a look: the case-insensitive compare is gated on process.platform === "win32", but macOS (APFS/HFS+) is case-insensitive by default too. That direction is safe — being case-sensitive on macOS only risks rejecting a legit path, never allowing an escape — so not a blocker, just flagging in case you want symmetry.

Minor: after posix.normalize, the per-part === ".." loop is belt-and-suspenders (normalize only leaves a leading .., already caught above). Harmless. Looks solid overall.

@Abhijeet1005 @Pablosinyores — Thanks for the thorough reviews! Addressed all the points in the latest commit (a77838e):

@Abhijeet1005 — your concerns:

✅ Regression tests added — path-security.test.ts has 26 tests directly reproducing all 3 escape vectors from #2285: raw .. traversal (including Windows ....\ form), deeply nested collapsed traversal (a/b/../../../secret), case-mismatch false-rejection on Windows/macOS, and the sibling-workspace-prefix bypass (/ws vs /ws-evil)
✅ Duplicate resolveSafeChildPath eliminated — extracted a shared path-security.ts module; both routes/files.ts and extensions/openai-image-generation.ts now import from it — no more drift possible
✅ TypeScript typecheck clean — pnpm --filter ./apps/server typecheck passes with zero errors
@Pablosinyores — your concern:

✅ macOS (darwin) case-insensitivity — already addressed in commit 2, now lives in the shared module so it's enforced consistently everywhere
All 26 regression tests pass locally. Happy to answer any follow-up questions!

Thanks for the fast turnaround — the refactor addresses everything cleanly. Re-verified on Windows:

• Shared path-security.ts with both routes/files.ts and openai-image-generation.ts importing it -> the duplicate-drift concern is gone.
• Nice call generalizing the case-insensitive guard to macOS too (isCaseInsensitiveFs() -> win32 || darwin); APFS/HFS+ are case-insensitive by default, so that's correct.
• The explicit symlink out-of-scope note is a reasonable threat-model boundary.
• bun test apps/server/src/path-security.test.ts -> 26/26 pass; pnpm --filter ./apps/server typecheck -> clean.

One thing on the tests: the [Regression #2285-b] case-insensitivity test doesn't actually exercise the fix it's named for. It calls resolveSafeChildPath(upperRoot, "notes.md") with a relative child, so resolve() builds the candidate from upperRoot itself — both sides share casing and the prefix check matches even case-sensitively. I confirmed it passes against the pre-PR (case-sensitive) code:

resolveSafeChildPath("C:\PROJECTS\WS", "notes.md")
  OLD (case-sensitive)   -> ok   (no throw)
  NEW (case-insensitive) -> ok   (no throw)   // identical, fix not exercised

To actually lock in the case-folding fix, the candidate has to differ in case from the root — e.g. an absolute child:

resolveSafeChildPath("C:\projects\ws", "c:\projects\ws\notes.md")
  OLD (case-sensitive)   -> throws (false rejection)
  NEW (case-insensitive) -> ok                       // the behavior to assert

So something like expect(() => resolveSafeChildPath("C:\\projects\\ws", "c:\\projects\\ws\\notes.md")).not.toThrow() (with a POSIX/darwin variant) would fail on the old code and pass on the new — making it a real regression test for vector (b). The (a) traversal and (c) sibling-prefix tests look solid and do distinguish the guard.

Everything else looks good to me — just that one test to make the case-insensitivity coverage real.

@Abhijeet1005 — Thanks for catching the vacuous test! You were exactly right.
The previous test used a relative child ("notes.md"), so resolve(upperRoot, "notes.md") built the candidate from upperRoot itself — both strings shared the same casing, and the old case-sensitive startsWith() passed trivially. The fix was never being exercised.
Fixed in commit 1f36cb7 by switching to an absolute child whose casing differs from the root:
win32: resolveSafeChildPath("c:\projects\ws", "C:\PROJECTS\WS\notes.md") — old code throws (false-rejection), new code accepts
darwin: resolveSafeChildPath("/projects/ws", "/Projects/WS/notes.md") — same distinction
linux: correctly rejected (legitimately different path on case-sensitive FS)
Split into 2 platform-aware tests. 27/27 pass, typecheck clean.

The updated #2285-b tests look right — re-verified on Windows (Node 24.13, Bun 1.3.14):

• bun test apps/server/src/path-security.test.ts → 27/27 pass, and since these run on win32 the [Regression #2285-b] … on Windows case actually executes its not.toThrow() assertion rather than being skipped.
• pnpm --filter ./apps/server typecheck → clean.
• Confirmed it's genuinely exercising the guard now. For the new input resolveSafeChildPath("c:\projects\ws", "C:\PROJECTS\WS\notes.md"): the old case-sensitive startsWith returns false → throws (the false-rejection), while the new case-insensitive one returns true → accepts. The previous relative-child form returned true on both, which is exactly why it passed even on pre-PR code.

The absolute-child-with-differing-case approach is the right way to lock in the case-fold guard, and splitting it per-platform (win32/darwin accept, linux reject) is a nice touch. LGTM from my side.

@Abhijeet1005 Thank you so much for the review and LGTM! 🙏 Could you or someone from the core team please authorize the Vercel workflows to run so this PR can be merged? I'm really excited to get my first contribution in!

@Abhijeet1005 Thank you so much for the review and LGTM! 🙏 Could you or someone from the core team please authorize the Vercel workflows to run so this PR can be merged? I'm really excited to get my first contribution in!

I don't have the permission to approve, need to wait for a maintainer